fix(compiler): read [class=…] from the prop the class list arrives on - #448
fix(compiler): read [class=…] from the prop the class list arrives on#448YevheniiKotyrlo wants to merge 2 commits into
Conversation
CSS 2.1 §5.8.1's own example is `span[class=example]`, and it matches nothing here: an attribute query built from the name `class` reads `props.class`, which no React Native element has, so every element answers false for every operator. The compiler already knows the mapping — a second class name in the same compound builds `["a", "className", "*=", name]` — so this routes both attribute-query build sites through one `attributePropName` rather than adding a third spelling of it.
`[class=…]` is the headline case and the four cases covered `~=`, `*=`, presence and the `:is()` build site — so the mutation proof never exercised the operator in the title. The new case pins both directions of §6.1's exact match: the value it compares is the WHOLE class list, so `[class='test example']` matches `className="test example"` and `[class='example']` does not — the same answer a browser gives for `span[class=example]`.
Device evidence — before / afterUNFIXED — All three bars are blue. The query reads FIXED — The first bar is red and the other two are blue.
One rule governs all three bars — The second and third bars are the anti-vacuity pair. They are blue in both frames, and the third is what says the withheld case looks like nothing rather than like everything: two bars that had both lost the rule would agree with each other perfectly, so the miss alone proves nothing. Both frames come from the same device in the same run (Android 36 emulator, 1140×2400 @ 480dpi), but The |
1 participant
Summary
[class=…],[class~=…]and[class]match nothing, on every element. CSS 2.1 §5.8.1's own worked example isspan[class=example].Problem
An attribute query built from the name
classreadsprops.class. React Native delivers the class list asclassName, so the prop never exists and every operator answers false:.test[class~='example']<Text className="test example" />.test[class*='xamp'].test[class]Solution
One mapping, applied at both build sites. The compiler already knows it — a second class name in the same compound builds
["a", "className", "*=", name]— so this routes both sites throughattributePropNamerather than adding a third spelling.Test plan
Five cases in
src/__tests__/native/attributes.test.tsx, covering=,~=,*=, presence, and the:is()build site. The=case pins both directions of §6.1 exact matching — the value compared is the WHOLE class list, so[class='test example']matchesclassName="test example"and[class='example']does not, which is what a browser answers forspan[class=example]. Mutation-proved: makingattributePropNamethe identity turns all five red and nothing else.yarn typecheckandyarn lintclean;yarn test1053 passed, 3 failed, 21 skipped. The three failures are two babel suites that fail identically on an untouchedmainworktree (Windows-only module-specifier rewrites) — this touches no babel file.Note
Independent of #447 — that one is what the operators do with a value, this is a name that never resolves. Both touch the same two build sites, so whichever lands second needs a trivial rebase. #449 is a third, same story.